Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

Reinventing the Annual Member Survey: A Business Analyst’s Role in Delivering Actionable Insights

Pulkit Singhal — Sun, 25 Jan 2026 02:38:00 GMT

In a competitive and rapidly evolving financial landscape, understanding member needs is vital to maintaining strong relationships and delivering meaningful value. Yet for many institutions, especially those with legacy processes, collecting structured member feedback can be surprisingly underdeveloped. This was the case at the Federal Home Loan Bank of Chicago (FHLBank Chicago), where — despite its extensive engagement with member institutions — the Bank had never before conducted a structured, enterprise-wide Annual Member Survey.

Recognizing the need for a formalized feedback mechanism, the Bank launched an initiative to design and implement its first-ever Annual Member Survey, leveraging Salesforce as the foundational platform. As the Lead Business Analyst, I was responsible for envisioning, architecting, and orchestrating this new capability from the ground up.

This initiative ultimately became a defining example of how strategic business analysis can create net-new organizational capability, not just improve existing processes.

The Challenge: Creating a Strategic Feedback Framework from Scratch

Unlike most process-automation projects, this effort did not begin with an existing workflow to analyze or improve. Instead, the Bank faced a unique challenge:

No prior survey process existed
No historical data or response structures were available to benchmark against
No distribution, tracking, or reporting mechanisms had been established
No governance model existed for how results should be consumed
Stakeholders possessed varying assumptions about what the new survey should accomplish

This meant the project required not only systems expertise but also conceptual design, stakeholder alignment, and strategic framing.

My Role as Lead BA: Designing a New Enterprise Capability

The absence of an existing process meant that Business Analysis would shape the entire direction of the initiative. My responsibilities included defining the business problem, creating the process architecture, establishing data structures, and ensuring Salesforce could support a sustainable and scalable survey model.

1. Establishing the Vision and Framing the Purpose

Through interviews and collaborative workshops with Member Strategy, Sales, Analytics, and Leadership teams, I led discussions to answer foundational questions:

What insights should the Bank gather annually?
How should “member satisfaction” be defined in measurable terms?
What KPIs would create genuine value for leadership?
How should results be tied back to member institutions in Salesforce?

This work produced the Bank’s first Survey Vision and Strategy Framework, guiding all subsequent design decisions.

2. Building the End‑to‑End Survey Workflow in Salesforce

Because no prior workflow existed, I architected a brand‑new process designed around clarity, automation, and scalability:

Designed the survey creation and distribution model
Built logic for survey-to-member linking
Defined the response-collection data structure
Modeled the end‑to‑end visibility lifecycle, including assignment, participation, reminders, and results
Ensured dashboards would give leadership real-time insights

The process not only captured survey responses but also embedded insights directly into the Bank’s member management ecosystem.

3. Translating Ambiguity Into Clear, Actionable Requirements

Given the lack of precedent, requirements had to be derived through deep analysis rather than comparison. I authored:

Detailed user stories
Acceptance criteria
Process maps
Data models
Reporting definitions

This documentation became the foundational blueprint for developers, testers, and end-users — eliminating ambiguity and creating shared understanding.

4. Leading UAT and Validating a New Capability

Because the Bank had never conducted a survey like this, UAT required additional rigor:

I designed test scripts covering every stage of the survey lifecycle
Trained business stakeholders on how to test a process that was entirely new
Triaged defects and clarified user expectations
Ensured the system was intuitive and future-proofed

Through this, the Bank gained confidence not just in the technology, but in the process itself.

5. Supporting Rollout, Adoption, and Governance

Beyond system delivery, I worked closely with:

Member Strategy teams to formalize interpretation of results
Analytics teams to align on scoring and reporting methodologies
Change management teams to ensure smooth onboarding
Salesforce admins to embed long‑term maintainability

This ensured the survey became an annual, repeatable, institution-wide capability—not a one‑off project.

Conclusion: This project shows that Business Analysts are not just process improvers—they are capability creators.By clarifying needs, defining strategy, architecting processes, aligning teams, and ensuring quality, the BA function enabled FHLBank Chicago to establish a powerful new insight mechanism that will shape strategy for years to come.

The Annual Member Survey is now more than a project deliverable.
It is a permanent intelligence asset for the Bank — built on a foundation of Business Analysis leadership.

6 Differences Between Data Exploration and Data Presentation

Zach Gemignani — Wed, 16 Mar 2022 18:55:00 GMT

There are big differences between data exploration versus data presentation. And you need to be aware of these differences as you're creating data stories and data presentations. Let’s start by defining our terms:

Data exploration means the deep-dive analysis of data in search of new insights.
Data presentation means the delivery of data insights to an audience in a form that makes clear the implications.

Your toolbox for data exploration tools is flush with technology solutions such as Tableau, PowerBI, Looker, and Qlik. "Visual analytics" tools give analysts a super-powered version of Excel for dicing data to facilitate the search for valuable insights. Flexibility and breadth of features is critical; the user needs to handle lots of data sources and doesn’t know in which direction she will go with the analysis.

Data presentation is a different class of problem with distinct use cases, goals, and audience needs. Think about the incredible data stories delivered by the The Upshot, Fivethirtyeight, and Bloomberg. These data journalists often demonstrate data presentation at its finest, complete with guided storytelling, compelling visuals, and thoughtful text descriptions. When compared to these examples, it becomes obvious that the best efforts by a data exploration tool cannot deliver high-quality data presentation.

You need a specialized solution if you really want to communicate data in ways that engage your audience. To understand the differences between data exploration and data presentation tools, let me offer six key ways that the activities are fundamentally different.

1. Audience — Who is the data for?

For data exploration, the primary audience is the data analyst herself. She is the person who is both manipulating the data and seeing the results. She needs to work with tight feedback cycles of defining hypotheses, analyzing data, and visualizing results.

For data presentation, the audience is a separate group of end-users, not the author of the analysis. These end-users are often non-analytical, they are on the front-lines of business decision-making, and may difficulty connecting the dots between an analysis and the implications for their job.

2. Message — What do you want to say?

Data exploration is about the journey to find a message in your data. The analyst is trying to put together the pieces of a puzzle.

Data presentation is about sharing the solved puzzle with people who can take action on the insights. Authors of data presentations need to guide an audience through the content with a purpose and point of view.

3. Explanation — What does the data mean?

For the analysts using data exploration tools, the meaning of their analysis can be self-evident. A 1% jump in your conversion metric may represent a big change that changes your marketing tactics. The important challenge for the analysts is to answer why is this happening.

Data presentations carry a heavier burden in explaining the results of analysis. When the audience isn’t as familiar with the data, the data presentation author needs to start with more basic descriptions and context. How do we measure the conversion metric? Is a 1% change a big deal or not? What is the business impact of this change?

4. Visualizations — How do I show the data?

The visualizations for data exploration need to be easy to create and may often show multiple dimensions to unearth complex patterns.

For data presentation, it is important that visualizations be simple and intuitive. The audience doesn’t have the patience to decipher the meaning of a chart. I used to love presenting data in treemaps but found that as a visualization it could seldom stand-alone without a two-minute tutorial to teach new users how to read the content.

5. Goal — What should I do about the insights?

The goal of data exploration is often to ask a better question. The process of finding better questions gets to new insights and a better understanding of how your business works.

Data presentations are about guiding decision-makers to make smarter choices. Much of the learning (through data exploration) should be done, leaving the equally difficult task of communicating the insights and the actions that should result.

In all these ways, data exploration and data presentation are different beasts. This is why we’ve chosen to focus on building the best possible data presentation tool, Juicebox.

6. Interactions — How are data insights created and shared?

Data exploration can be a lonely endeavor: Analysts work on their own to gather data, connect data across silos, and dig into the data to find insights. Data exploration is often a solitary activity that only connects with other people when insights are found and need to be shared. That is, when…

Data presentation is a collaborative, social activity. The value emerges when insights found in data are shared with people who understand the context of the business. The dialogue that emerges is the point, not a failure of the analysis.

Finding the Middle Ground: Data Storytelling

There is something between the extreme ends of data exploration and data presentation. We believe data storytelling lies in this intersection. Data stories aren’t entirely about “telling”, nor are they in the wilderness of “finding”. It is the opportunity to explain the data in a guided, narrative way where message meets exploration.

While there are tools for exploration (e.g. Tableau) and tools for presentation (e.g. PowerPoint), it is only recently that you’ve had the change to bring both together in one solution.

Zach Gemignani (zach.gemignani@juiceanalytics.com)

CEO, co-founder, author at Juice Analytics

www.juiceanalytics.com

Product Evaluation Framework for a BA

Ashish Adike — Tue, 20 Oct 2020 22:36:00 GMT

As a Business Analyst, very often we get into a situation where the Project requires multiple IT Products to be evaluated before implementation and might seek Business Analyst’s recommendation for the same. With the ever-growing range of Products in the market and the marketing promotions associated with some of the products, it’s very easy to choose the Product with most features or the most famous one. While there are various benchmarking softwares that measure the IT products from a technical performance perspective, as a Business Analyst, it is our responsibility to make sure that the right product is chosen as we are the ones who know the Business Processes closely and at the same time are equipped to understand the features of a Product that would be well suited to address the Business Requirements. While a Business Analyst may not be the final decision maker, the BA’s analysis definitely impacts the decision-making process. A structured approach to analyze the available Products would help in choosing the best suitable IT product for the Business.

Features: It is recommended to choose a Product that has Features which meet most of the Business Requirements out of the box. Although it’s difficult to find a Product which would satisfy 100% of all the required features, it’s better to choose the one with as little customizations as possible. Customizations would often mean force fitting a Product for a Business Process and may have downstream impact in future. Also, it would involve high maintenance costs to maintain a highly customized Product. As a Business Analyst, we need to provide a Business Process vs Feature mapping for each of the IT Products in question, which would enable the Stake holders to choose the IT Product satisfying the most relevant and critical Business Processes.

User Experience: As a Business Analyst we generally work closely with the Business Users and can gauge the pulse of the Users. It is important that any IT Product chosen provides a good User Experience as it would drive the user adoption and hence the success of the Project. The Business Analyst needs to capitalize the demos provided by the respective IT Products to determine the User Experience levels. Also, many IT Products are available on a free trial version, which can be utilized to get a feel of the Product hands-on before actually implementing the same.

Support: Once an IT Product gets implemented and as the Business Users start adopting it, we see a lot of enhancement requests coming from the Business Users to improve the existing implementation. Also, there might be Bugs in the Product which got missed in the testing process but arise only when the users start using the Product. In order to resolve the issues and implement the enhancement requests, it is critical to have a good post implementation support from the respective IT Product Vendor.

Ease of access: The ease with which Users can access an IT product also plays a vital role in determining the right Product. A Product which can be accessed from any web browser (i.e. Cloud) would always rank better as compared to a desktop based (i.e. on premise). It would even be better if the Product can be accessed from a Mobile device. With the work-from-anywhere concept gaining prominence, the Cloud based, and Mobile enabled Products would see an upward trend in demand.

Product Roadmap: It is important to consider the roadmap the IT Product has planned for implementing various out of box features as that would help us in planning our implementation and make decision on the level of customization that needs to be done during the initial release. The IT Product with promising features suitable to the Business Requirements needs to be given a higher priority as compared to that without a suitable Roadmap.

Although the cost and performance of the IT Product might be considered by the Management, a careful analysis of the IT products with respect to above listed parameters would help the Stake Holders in choosing the right IT Product for long term.

About the Author:

Ashish Adike is a seasoned Business Analyst with more than 8 years of experience in Business Process Analysis, Requirements gathering, Consulting, Solutioning and Project Management. Experienced in working with multiple Business functions – Sales, Marketing, Finance, Operations. Strong research professional with a PGDM focused in Sales and Marketing from Indian Institute of Management, Indore. Awarded team player with excellent learning and adaptability skills.

Are You Being a Design Illusionist?

Paul Crosby — Wed, 07 Sep 2016 14:31:00 GMT

As business analysts, we are often in the fray of designing. Whether it’s a user interface, report or data fed from one system to another; business analysts create interfaces with human beings and systems. Our design choices impact users and other systems in a very real way. This power can go unnoticed even in our own minds.

Have business analysts become illusionists and pickpockets? Both these skill sets require some of the same sleights of hand. The illusionist uses the blind spots and limits of human vision to fool us. If you haven’t had an opportunity to watch the show called “Brain Games” – give it a whirl. It does an excellent job of explaining how an illusionist can fool our sight and point of view. For the pickpocket, it’s the distraction of a conversation, a tap, or a bump to set your mind off in the opposite direction of where you should be focusing while a sleight of hand takes your wallet.

Are we as business analysts playing a role of illusionist and pickpocket when designing our interfaces? Let’s look at interfaces (such as screens and reports) in a broader sense. An interface in my mind is the presentation or “stage” an illusionist would use.

We all believe we have choices and freedom. Everyone in the western world most firmly believes they have great freedom of choice in being able to do whatever is desirable, affordable and of course legal. You can go just anywhere and do just about anything. But when confronted with a system, website or application with a menu of choices, we fail to see how we are hijacked.

We rarely ask the questions:

(1) What is NOT in the interface? Or why are these my only choices?

(2) What is the purpose or goal of this interface? What is it used for?

(3) Why are these options higher or lower on the interface? More visible or less visible as other choices?

(4) Are these choice empowering me or just distracting me from doing what I need to accomplish?

If you have every used a search engine like Google or an application like Yelp, you get a sense choices are made for you and only certain things are being presented for your attention. I have been told the nearest restaurant or gas station is several miles away – all the while standing right in front of one! I usually chalk it up to “well they must not have gotten into the database yet” but now I’m leaning more to thinking I’m being fooled by the choices I’m presented.

Back in the ancient days at the dawn of computerized civilization – something like 40 years ago for you youngsters – computers were called mainframes. Mammoth monsters that would manage large amounts of data, electricity and generate a lot of heat. They required a forklift to move and had to be water cooled.

In those ancient days of computer myths and data Gods, there was but the humble green screen. To get to all the crap stored in that giant mainframe required you to issue the magic commands. By locating the secret words in the sacred text called “Command Line Reference,” you could instruct the mainframe beast to perform feats of great wonder. In other words, there was a giant three-ring binder with all these commands listed in alphabetical order that you were required to memorize and type correctly. The mainframe didn’t tolerate spelling mistakes, and there was no such thing as auto correct. No Google-like “Is this what you mean?” ever appeared on the screen. Even the help key which was supposed to provide assistance rarely did. This was the world of complete freedom from “the menu”. All the commands were in the book and available and granted they didn’t cover everything you wanted to do, but they did cover a lot of stuff you needed to perform. Yes, you had to memorize a boat load of command line syntax because the mysterious book appeared and disappeared as it desired, but you never felt limited rather you just felt a need to search for the right command.

Enter the age of the personal computer. For simplicity, the command line went away. The mouse was born. There was nothing more entertaining than watching grown men in a room holding the mouse with both hands tightly but gently trying desperately to get that arrow moving in the right direction on the screen. “This mouse thing will never catch on” they grumbled. Suddenly the command line was gone, and menus or buttons presented to us. These were your options. Your only available commands. It didn’t take long before I missed my giant 3-ring binder of commands that gave me all the power.

Over time we became to believe that only the commands we could see were the ones of importance. We would become less and less frustrated at not seeing the things we needed. We are restrained by choices of actions presented. Our perception came to be that if it wasn't presented, it wasn't available.

So let’s take this into the modern smartphone age. The other night friends and I were out at a restaurant having a great conversation. The restaurant was closing because it wasn’t that busy and the owner wanted to call it a night. We asked each other the question “let’s continue this conversation – where should we go?”. We all pulled out our smartphones pulling up Google, Yelp, and the other thousand apps on our smartphones looking for a place that was open late. This searching went on for 15-minutes or so. Now I can be a bit impatient with technology and frankly don’t always find it of much help in situations like these. I quit my search letting the others wade their way through the digital data flowing around with smartphones. Then I looked up.

A beautiful park lay right before our eyes across the street, and we didn’t even see it. We believed our only options to find some place were those our smartphones provided. Did those applications tell us about the park? Not one. How about that food truck with the fabulous desserts? Nope. Not a single one. Our illusion of having choices was broken. Sure we got a lot of options, but it was all about the pictures of the menu or comments from other people that distracted us from answering the exact question “Where should we go to keep talking?”. The menu or interface design didn’t answer our actual question at all. It created the illusion of choice by presenting a small subset of options. All said and done the park was bug-free which is a miracle in Minnesota some evenings. Dessert and conversation continued for hours in the street lamp lit park.

As business analysts or designers, it is easy just to limit user choices to a few as possible to send them down a well-defined and perfectly groomed path. But does that answer their question? How many times have you wanted to say “Siri – lead the way to a great evening with my friends!”. The response from Siri is, “I’m sorry I don’t’ understand what you are asking”.

There are a thousand paths to getting or achieving something. No matter how hard you try to make it simple, it just winds up being even more complicated. Or worse the real thing you need is hidden somewhere because someone felt it wasn’t’ important enough to warrant a button. Some of the best interfaces look very simple on the front end and have a rich set of commands just slightly inside of the interface. As a business analyst and designer, we need to give our users or community a rich experience with our application. Are we the illusionist – forcing users down only one path? Our accounting system has several ways in which to generate an invoice. From a customer contact screen, main menu, sidebar and I’m sure more options remain hidden in the accounting interface. As I watched the finance, customer service, and sales people utilize the user interface with the simple task of generating an invoice, I noticed something important. Not everyone went about taking the same path.

Sales people always went to look at the customer inquiry screen first before generating an invoice. Individuals and their contact information were more important to them, and they would update it before moving on to creating an invoice. Customer service created invoices from the order screens as they were more focused on shipping products. Finance folks just clicked on the main menu option.

Know your users. They each have a story and a way of performing tasks that make sense to them. Think about their “persona” and what they need to accomplish. There is no single path to creating an invoice. Develop a list of capabilities and make sure they are not “hidden” from view. If it all doesn’t fit on a screen, find ways to expand the options for display when requested. Don’t fear including two buttons “Create Invoice” and “Add Invoice” which go to the same screen if it makes more sense to a broader audience of users. It is more about clarity for your users then consistency in terms.

What has a dinner in the park taught me? Smartphones are not as smart as we think they are. Everyone thinks they have choices, but don’t always see the most obvious choice because the choice is not presented in a way the user would understand. Question the choices presented and determine if they are the only choices.

Yes, I still miss my green screen terminal. CMD-1 key forever will mean “useless” help, and a blinking green bar on a black screen will always be a symbol of the endless possibilities to mistype ridiculously long string of text that doesn't make sense to anyone. And that huge 3-ring binder filled with commands-a-plenty works damn good propping the door open.

For more good stuff on business analysis and leadership, check out the blog at Bob the BA.

6 ways to effective prototyping

Surbhi Mahnot — Mon, 12 Oct 2015 06:28:00 GMT

Prototyping is a speedy creation of a full-scale model that helps evaluate a product without investing in actual development.

It promotes effective communication
Decreases development time
Decrease chances of costly mistakes at later stages

But the temptation to build something out-of-the-ordinary, being exceptionally creative and unique prototypes, often steals time away from other important tasks and we end up making it a task big enough as developing a system without code.

Here are a few simple guidelines that could help in creating prototypes effectively.

#1 Prototypes should be “good enough”

Prototyping tools provide enough capabilities to build up an entire product without writing a single line of code.
Unfortunately at times when we are halfway through the project, confident enough, reality hits. Changes creep in and to keep pace with the time and requirements we break the flow down and a bunch of prototyping efforts is lost and rendered wasted leaving the original plan all messed up!

Your prototype doesn’t have to be pixel perfect and development ready, they just need to be good enough to convey the thoughts as a visual representation.

Remember, the main purpose of prototypes is to always help stakeholders visualize the requirements & gain quick feedback to eventually move forward with actual designs.

Restricting the scope of each prototype frees you to focus on what is most required at the point of time.

Get things looking good enough and move forward.

#2 Prototypes should have a clearly defined goal

While rapid prototyping, it is good to have a purpose or a goal in mind. These can be

Gain customer feedback
Present and convey organizational plans
Share project ideas with potential clients and prospects
Help UI designers know the project better

Knowing the purpose of the prototype clearly helps you define the project scope and determining how detailed the prototypes should be.

Rough sketches help you move faster. A lot of tools such as Balsamiq, Sketch, Moqups provide this ability to quickly sketch a prototype with lo-fi (low fidelity). This brings up to our next point.

#3 Always try to determine prototype fidelity at earlier stages

It is always helpful to determine the fidelity of the prototypes in advance to save plenty of time at later stages where more focus should be given on team communications and understanding development efforts. A clear picture of what is to be done determines the prototyping cost and efforts as well.

The fidelity could be identified as

Low fidelity (lo-fi)
Use: Give insight of all the features and content for the project
Traits: Sketches, black and white representation
Mid fidelity
Use: Considering as transitional phase that allows more flexibility, creativity and interaction
Traits: Sketch, black and white /color representation, interactions to make the navigational flow clearer
High fidelity (hi-fi)
Use: Almost a replica of the exact design. A pixel-perfect version of what would actually look like when complete
Traits: Pixel-perfect in terms of color, margins, layout, dimensions, content, navigation, animations, etc.

The fidelity could be measured in following dimensions

From project scope — what screens are required to be created?
Do we need a quick sketchy mockups with lo-fi or mid fidelity or we need hi-fi?
The content on the screens should be “real” or dummy content of ‘lorem ipsum” would go?
Do the navigation needs actual transition effects or animations or basic click based flow would work?

Agreeing early at the fidelity of prototypes could save from lengthy last minute discussions leaving the client disappointed.

#4 Test as you go

While creating prototypes, it is common that we put extra efforts to showcase the creativity and innovations. But while doing so often in the midway, we lose our rhythm, consistency, and sync between screens.

At the end of the task, it can be real hard to figure what exactly went wrong in the course of time, where the interaction is missed, where the consistency is lacking and it all ends up spending an entire day or even more time to correct the flow!

It is very important to “test the flow” continuously as you build the screens to get things done sooner and without errors.

#5 Reusable building blocks

Prototyping has become a lot easier with modern tools available to provide several techniques that help improve the productivity. In most of the popular tools there are options to create styles and symbols which can then be reused very easily.

For e.g. in Balsamiq tool, it is very easy to create a symbol.
Just select the elements -> Convert into symbols -> Name the symbol. The symbols file is then created which can be directly used as widgets.

This 10 minutes initial time consuming task will definitely help in subsequent cycles by saving hours of rework. An update in symbols file will update all the occurrences at just one go! Saving a good amount of time, isn’t it?

There is no alternative to hard work. But, being smart can boost the work hard which can empower you to be innovative rather than being repetitive!

#6 Share the prototypes — early and often

Share your wireframes early and often with the involved stakeholders. Continuous collaboration always helps in building a better product.

Collecting feedback frequently helps in identifying missing details and even feasibility of the components in terms of development.

There are many tools that help collaborate easily like Trello, Slack, etc. For example, a popular tool InVision provides real-time collaboration to be ahead of time always.

Create a solid base with effective prototypes to collect customer feedback, improve the processes and always be in right direction. Hope these guidelines might help you in saving a good deal of time, cost and efforts.

Happy Prototyping!

The article was published originally on Medium.com by surbhimahnot

New Axure Book on Amazon - Reviewers Needed

Anna Roosen — Mon, 24 Jun 2013 09:43:00 GMT

Hi all,

I have recently co-authored a new book on using Axure RP ("A Beginner's Guide to Axure 6.5"), and would like to hear from BAs/UXers/Interaction Designers who would be interested in writing an independent Amazon store review for the book, in exchange for a complimentary kindle copy. Please contact me at annaroosen@gmail.com.

Amazon link: http://www.amazon.com/Beginners-Guide-Axure-6-5-ebook/dp/B00DK8YZ3W/ref=sr_1_9?ie=UTF8&qid=1372070434&sr=8-9&keywords=axure

Blurb: “A Beginner’s Guide to Axure 6.5” is written for anyone involved in software design who needs to learn how to use Axure RP 6.5 in a minimal amount of time. Axure is a leading prototyping tool used to create rapid "drag and drop" designs for web, desktop and mobile applications, without the need for code.

No previous knowledge of the tool is required to use this book, and the two expert-level authors take you right from the basics and cut through to the essential skills you really need to create rich interactive designs. Many examples and practical real-world tips are included to help improve the quality of your designs and make your prototyping more efficient.

Concepts and techniques covered include: Getting started, the Axure interface, file management, the main menu, managing panels, the sitemap, page notes, the canvas, guidelines, widgets, annotations, designing using only images, modifying widgets (widget-by-widget formatting, global formatting and widget libraries), page formatting, masters, how to create consistent designs, simple widget interactions, simple page interactions, dynamic panels, simple and complex interactions, shortcuts, generating prototypes, generating page images, creating flowcharts, generating specification documents, providing prototypes to clients, and designing mobile applications.

From Verbal to Visual: Reviving the Lost Art of Prototyping

Stephanie Famuyide — Sat, 16 Feb 2013 09:49:00 GMT

“Something is happening. We are becoming a visually mediated society. For many, understanding of the world is being accomplished, not through words, but by reading images –

Paul Martin Lester, “Syntactic Theory of Visual Communication

Research has shown that communication with a visual dimension is more effective than communication without. Herome Bruner of New York University revealed that people remember only 10% of what they listen to, only 20% of words they read and about 80% of what they see and put into practice.

Though visual communication is deemed more powerful than verbal communication, a combination of the two, carefully and intelligently blended can be extremely powerful.

Look around you. Visual communication is everywhere - from presentations at work to directions on the street. Today’s generation now lean towards a different mode of learning; there's a pervasive preference for videos, pictures, flashcards and presentations. Communication is now achieved visually more than ever.

Beyond the ability to deliver compelling presentations, the perfected art of visual communication can be extremely useful when dealing with stakeholders. Understanding a 10-page business requirements document can be made easier if the business analyst employs the use of mock-ups/prototypes and process diagrams.

Edward R. Tufte has emphasized that “To envision information—and what bright and splendid visions can result—is to work at the intersection of image, word, number, art.”

Employ the use of charts, diagrams, tables and colours wherever you can to deliver a powerful combination of the visual and the verbal.

Next time you're churning out that business requirements document, consider using pictures instead of a thousand words....

Stephanie Famuyide (Stephanie@businessanalystlearnings.com)

http://businessanalystlearnings.com